Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000007_owner-urn-ietf _Tue Oct 8 00:31:56 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA27517 for urn-ietf-out; Tue, 8 Oct 1996 00:31:56 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA27512 for <[e-mail]>; Tue, 8 Oct 1996 00:31:17 -0400
Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA10993  (mail destined for [e-mail]); Tue, 8 Oct 96 00:31:10 -0400
Received: from nic.cafax.se ([e-mail] [193.12.122.42])
        by nic.cafax.se (8.8.Beta.2/8.8.Beta.2) with SMTP
        id GAA23257;
        Tue, 8 Oct 1996 06:30:41 +0200 (MET DST)
Date: Tue, 8 Oct 1996 06:30:40 +0200 (MET DST)
From: Patrik Faltstrom <[e-mail]>
X-Sender: [e-mail]
To: Larry Masinter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [URN] advantages of NAPTR over PURLs
In-Reply-To: <96Oct7.191009pdt."2771"@golden.parc.xerox.com>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: Patrik Faltstrom <[e-mail]>
Errors-To: [e-mail]

On Mon, 7 Oct 1996, Larry Masinter wrote:
>
> > We can provide multiple A records for www.purl.org, but there is no
> > way to do smart prioritization between the more and less capable
> > hosts.
>
> Why is this easier to do with NAPTR records than A records? Could we
> extend A records for HTTP servers so that you could do smart
> prioritization? ("If this is such a great idea, why save it for
> URNS").

The A record does not have a priority. MX-records do have that,
A records does not. You can not change the spec of A-records.

> > Depending on how the multiple A records are provided, there may also
> > be an obscure error that truncates the list of responses. The NAPTR
> > proposal will not suffer that error.
>
> Is this a bug in the implementation of DNS? If the bug is there for A
> records, why wouldn't it be there for NAPTR records? Is this a design
> error that could be fixed?

This is just how things are implemented, especially when one
start using things that is not really DNS (NIS for example).
To be able to get around this problem -- we need a new resource
record type.

> > The real point of the NAPTR proposal is that it gives us a way to cope
> > with names, such as www.purl.org, that should be long-lived but aren't.
>
> I don't understand why www.purl.org must have a shorter lifetime than
> any NAPTR name. You just vow to not reassign the name. If you can't do
> that with ".org", then pick a new top level domain.

Because the NAPTR record is the second abstraction level you really
need to be able to handle renaming of resources on the net. You also
can handle other protocols than HTTP which makes the NAPTR proposal
(NAPTR records together with SRV records) much more long lived.

> The DNS entries for resolver.purl.org already give you all the
> indirection you need. Why add more?

No, it does not give the information about priority and
protocol that is needed. We should not at all of the meetings
we had last year still be talking about NAPTR records which
forces everyone to change their resolvers if it was not needed.

The PURL methods do work for locating HTTP servers, IF you
name your resources exactly the way you point it out Larry,
i.e. that you do have a special namespace allocated for the
PURL names which does not have anything in common with the
hostname namespace.

When coming to this conclusion, we did also think about the
need for different resolution protocols (to handle the case
when someone is running a resolution service for a publisher,
and who is responsible for what in the resolution process)
and especially for priority between different servers with
different access protocols. I.e. PURLS solves tons of
problems with URLs that we have today, but it does not solve
the requirements in the URN requirements paper.

We have some people thinking that not even the NAPTR proposal
does that -- and we have not claimed that NAPTR solves the
URN naming problem. The URN's do solve the problem by later
having functionality of grandfathering the NAPTR scheme
into some other scheme later on -- when DNS is replaced :-)

> >We are not talking about the same thing. One could assign PURLs such as
> >   ftp://purl.foo.com/whatever
> >but once that PURL is assigned, we have to use FTP to resolve it. Since
> >the NAPTR draft doesn't require the resolution protocol to be embedded in
> >the identifier, we are free to offer multiple resolution protocols and to
> >change them over time. This is an important point, since over time we
> >will have increasingly efficient protocols.
>
> In the "PURL" method, the "resolution" is accomplished by using HTTP
> to talk to the resolution service and (if what you do is a GET)
> getting back a "303" response with a Location: header to do the
> URN->URL mapping.

This is exactly what one of the problems is. We think that DNS
that have been around for some years is more stable than HTTP.

What do you do with PURLs if HTTP is replaced with something else?
Or if you have one primary server handling FTP and a secondary
one using HTTP and a third HTTP++ (whatever that can be?). In
the PURL scheme you _HAVE_ to have one primary protocol which is
served on each one of the servers:

  ftp://purl.acme.com/  ===>  Use FTP to connect to purl.acme.com

  purl.acme.com. IN A foo.acme.com
  purl.acme.com. IN A bar.acme.com

Both of these servers _have_ to have ftp access
and both _have_ to have the ability (if needed)
to give a redirect to the protocol which is
needed to access that perticular server.

In the NAPTR proposal, each one of foo.acme.com
and bar.acme.com can, part from being
prioritized also use different access protocols.

> > For PURLs, we not only have to know the identifier, we have to know
> > what resolver to contact. We end up with things like:
> >   http://purl.bowker.com/isbn/1-56604-355-7
> >   http://purl.agicoa.com/isan/9961231234567891
>
> oh no! Clearly you only want to use the resolver.purl.org name.

Or rather:

http://purl.bowker.se/isbn/91-46-14140-5
http://purl.bowker.se/isbn/46-14140-5
http://purl.bowker.se/isbn/4614140-5
http://purl.bowker.se/isbn/46141405
http://purl.bowker.se/isbn/9146141405

...which all might have to be supported if you use HTTP as access
protocol (with todays HTTP backends which PURL uses).

If you allow a different "ISBN-resolution-protocol" to be the
access for ISBNs, which we can handle in the NAPTR proposal,
we solving naming problems on the right level of the stack.

   Patrik